           Ambient RF Propagation for Communications in Ada
                      Contract N66001-85-C-0042
                              Final Report
                             1 October 1985

                            IWG Corporation
         975 Hornblend St., Suite C, San Diego, CA 92109


OVERVIEW
     The conversion of the SIMSTAR ambient RF propagation routines to 
Ada has been completed.  The Source code (CDRL A001), the executable 
code (CDRL A005), and the users manual (CDRL A003) resident on the NOSC 
TECR in directory [CONTR41.PROPLINK].  This final report contains 
additional information concerning PROPLINK and a discussion of the 
problems encountered and lessons learned during this project (CDRL 
A002).  New features should be considered for future additions.
 
PRODUCT DELIVERY
     Proplink is a stand-alone RF propagation prediction program which 
allows easy use of the SIMSTAR RF propagation routines through an 
interactive front-end processor.  It allows the user to describe a 
complex network of links by node, receiver, and transmitter 
descriptions.  The signal and noise at each receiver is calculated using 
one of the five propagation modules: ELF, VLF, LF, MF/HF, and 
VHF/UHF/SHF/EHF.   Detailed instructions are given in the user's manual 
which can be found in the file PROPLINK.DOC in the directory [CONTR41].  
World read access as been given for this file.  The User's manual 
includes a sample PROPLINK session and a Package "Withing" Map.  The 
source code (.TXT) and executable code (.SYM) can be found in 101 files 
in directory [CONTR41.PROPLINK].  The code has been compiled under 
Telesoft Ada 1.5 and will execute with the command TRUN PROPLINK.  Also 
included on the directory are four seasons of Noise data and several 
sample data sets: ELFTEST.DAT, VLFTEST.DAT, LFTESTD.DAT, LFTESTN.DAT, 
HFTEST.DAT, and VHFTEST.DAT.  These test data sets have been run on both 
the FORTRAN version and this Ada version of PROPLINK to verify the 
accuracy of the Ada version.  It should be noted that PROPLINK includes 
several useful packages in addition to the propagation routines.   
ENTITYUTI provides useful utilities for parsing an input string, and 
storing alphanumerics as integers.  COMPLEX is a complex number package.  
IOANDFILE contains some generic file handling utilities.  NODELOC does 
great circle geometric interpolation and extrapolation.  It is hoped 
that these routines can be used in other Ada software.
     The product is competitive with current FORTRAN simulation 
capabilities.  In view of the current state of Ada, the product may be 
years in advance of the user community.  Once Ada embedded systems 
software becomes more prevalent, PROPLINK should realize its potential 
in the Ada community.  In particular, it could be used to design, test 
and simulate any system performance where hardware communications is an 
issue with the potential for dramatic cost savings.   

PROBLEMS ENCOUNTERED AND LESSONS LEARNED.
     At the outset of this project, we knew little Ada and had no 
experience with an Ada compiler.  The problems we had and their 
solutions should be of interest to future users. 
     The greatest difficulties were related to the currently available 
Telesoft compilers 1.5 and 2.1.  We started out with 2.1 assuming that 
the newer version would be better for program development.  One NOSC 
employee said that he always uses 2.1 now that it was available.  After 
a week of extremely long compilation times (over an hour of CPU for 1000 
lines of code) we turned to 1.5.  When Colonel Whitaker heard about our 
switch to 1.5, he said that he wasn't surprised since no one has ever 
attempted program development on 2.1.  It would have been nice to know 
that earlier.  
     But even 1.5 was slower than we had ever imagined.  This is largely 
due to the heavy usage of the NOSC TECR.  At night, the compilation 
times are not unreasonable.  Every attempt was made to compile at night, 
although a reoccuring back end error precluded reliable use of batch 
compilation.  Therefore, some daytime compilation could not be avoided.  
During the final day of the project (the last full compilation) the 
slowing of the computer drew the operator's attention.  Rather than 
simply sending me a message to refrain from further compilation, she 
just reduced the account's priority.  Fortunately, this blow took place 
at the end of the project.  Future users should be warned that night 
work is required and that day compilations should be held to an absolute 
minimum lest you raise the operator's wrath.
     Another factor in the compilation time was the size of the 
packages.  Many of them are over 1000 lines long.  The packages were 
designed to group the subprograms logically by function.  
Unfortunately, they were large.  Perhaps future users might consider 
smaller packages to start with the intention of repackaging at the end 
once compiler errors are fixed.  The time saved during compilation 
would more than make up for the time it would take to repackage,
     Some major deficiencies in the 1.5 facility affected the progress 
of the project.  First, the lack of a Mathlib was caused some delay 
before one was located through Bruno Witti at NOSC.  He had recieved it 
from Colonel Whitaker some time earlier.  The availability of that 
package (and other utilities) should be made clear to future uses at the 
outset, not when they need them.  The mathlib did not include the 
complex number functions which are available in FORTRAN.  Therefore it 
was necessary to write and test a complex number package.  It is hoped 
that this package will find its way into an Ada library so that other 
users can benefit from it.
     Second, the lack of a symbolic debugger was a great hindrance 
during the final debugging stage.  Early on (January) we were told that 
the TECR would have the DEC Ada compiler, which has a debugger, 
available as soon as they went to VMS 4.2.  The estimated date for this 
was said to be May at the latest.  As of the writing of this final 
report, the TECR is still under 3.7 and no debugger is available.  
Therefore, the archaic methodology of inserting Put statements into the 
code and recompiling the package was used to clean PROPLINK.  It was 
found that this technique was at least five times slower than it took to 
check the same variables with the FORTRAN debugger.  It is hoped that 
future users will get the benefits of an Ada debugger. 
     Finally, a library utility would be helpful.  The fact that the 
final directory has 101 files in it is evidence enough of this need.
     Turning to the conversion process, the serial approach used in this 
project had benefits and drawbacks.  In this approach, one person did a 
quick and dirty conversion from FORTRAN to Ada and the other 
concentrated on compiling, debugging, cleaning, refining and, basically, 
making it work. The primary advantage to this approach was that each 
person got very good at their task.  In both cases a two or three fold 
improvement in effiency was seen.  The only disadvantage was a disparity 
in the relative hours that each job took.  While the initial conversion 
took 10% longer than originally estimated, the cleaning task took almost 
30% longer than expected largely due to the problems described above.
     Qualitatively, the serial approach impacted the final result in 
that some Ada features were not used to their full advantage.  By 
converting the FORTRAN line by line to Ada, we missed the chance to make 
some sweeping changes to the way data was handled in the program.  In 
particular, better use of record types could have been employed if they 
had been designed prior to any conversion. In future projects, I would 
recommend that the programmers study the variables to determine whether 
advanced Ada types could be employed.
     The FORTRAN version of PROPLINK is not well structure at the 
subroutine level; "spaghetti code" abounds.  There is heavy reliance on 
GOTOs.  At the outset, it was thought that this would be a major problem 
for conversion.  In fact, while difficult at times, it did not cause the 
errors we had expected.  Therefore, future users are encouraged to 
replace as much "spaghetti code" as possible and strive for "structured 
programs".   
     The most difficult aspect of the conversion was the replacement of 
FORTRAN common blocks with several packages which are "withed" by many 
other packages.  A major effort was made to reduce the number of 
variables that were passed between subprograms are parameters.  The 
problems occurred because the original FORTRAN used the same name for 
different variables, different names for the same variables, and the 
same name for the same variable in different units (e.g. FREQ is used 
for hertz, kilohertz, megahertz, etc.).  Other problems included 
incorrectly determining the proper mode of a formal parameter and 
redeclaring a variable inside a procedure which was declared in a withed 
package.  The result in both cases was the called procedure did not have 
the proper value for the variable.  Perhaps the most bizarre problem of 
this kind involved a FORTRAN subroutine which dimensioned an array but 
did not initialize it.  In the Ada version, the array was declared 
inside the procedure.  In fact, with each call of the FORTRAN 
subroutine, the previous values were retained; the Ada declaration 
effectively zeroed the array with each call.  The problem was solved by 
moving the Ada declaration to the top of the package body.  Once 
compiled, the majority of the remaining bugs were due to problems with 
passing data between packages and subprograms.  Future users should be 
cautious with passed data via calling parameters or withed packages. 
     Overall, the project was very worthwhile, particularly in that it 
resulted in an Ada capability at a small business that would not have 
been achieved by any other means.  The advice, assistance, and 
cooperation of the program managers and NOSC personnel was invaluable to 
the success of this project and is greatly appreciated.  
           
FUTURE EFFORTS
     Concurrent with this conversion, several additions and 
modifications have been made to the FORTRAN version of PROPLINK.  Its 
increasing use as a companion tool with SIMSTAR has brought out the need 
for several new features.  These include:

1)  Increased flexiblity and user-friendliness of the front-end,
2)  Output of signal-to-noise ratios and the ability to define a
    threshold S/N.
3)  Knife-edge propagation for VHF
4)  Tropospheric propagation of VHF
5)  Meteor Burst propagation
6)  Laser links

     Some of these have already been included in the FORTRAN version; 
all can be included into the new Ada version.  As Ada users of Proplink 
expand, these new features will be very useful.  The conversion of 
SIMSTAR to Ada is a major effort which requires a complete re-design to 
correct the many existing deficiencies of the FORTRAN and to take 
advantage of Ada's advanced capabilities. 
  
ec. Whitaker, Courtwright, Loper, Schill
cc. Gratt, Becker, Perry, Conrad


      
  
